Method and system for providing a circle of trust on a network

ABSTRACT

Embodiments of the present invention provide a circle of trust on a network. The circle of trust is configured by exchanging credential of a first and a second affiliated entity. The credentials of the first affiliated entity is stored in a trusted partner list of the second affiliated entity. The credentials of the second affiliated entity is stored in a trusted partner list of the first affiliated entity. Thereafter, a circle of trust session may be provided when a client device initiates use of a resource on a relying party device by providing an authentication assertion reference. The identity of the issuing party of the authentication is determined as a function of the authentication assertion reference. The relying party sends an authentication query containing its credential to the issuing party. The issuing party determines if the relying party is a trusted entity based upon whether the relying party&#39;s credential is contained in the trusted partner list of the issuing party.

FIELD OF THE INVENTION

Embodiments of the present invention relate to network security, andmore particularly to providing a circle of trust among a plurality ofassociated entities.

BACKGROUND OF THE INVENTION

Referring to FIG. 1, a block diagram of a network according to theconventional art is shown. As depicted in FIG. 1, a plurality oforganizations 105, 110, 115 are communicatively coupled by one or morecommunication channels 180 185, such as the internet or extranet. Eachorganization 105, 110, 115 typically comprises a plurality of clientdevices 120-150 communicatively coupled to one or more servers 155-175.The servers 155-175 provide one or more resources, such as execution ofapplications and/or storage of information.

A user on a client device 120-150 may be granted or denied access toresources of a particular server 155-175. In the conventional art, theclient 120 logs-on to a particular organization's server 155, whereinthe user provides a user name, password and/or the like. Based upon theuser name, password and the like, the server 155 authenticates theclient 120 and determines the client's 120 authorization to accessparticular resources.

If the client 120 then tries to access resource on another server 170,175, establishing authentication and utilizing resources is problematic.The other servers 170, 175 do not know that the client device has beenauthenticated by a particular server 155. The other servers 170, 175 donot know that they can trust the authentication provided by theparticular server 155. Furthermore, each entity 105, 110, 115 and/orserver 155-175 may have a different login script, may require adifferent protocol, may store information in a different structure,format and/or the like. Therefore, the client typically has to sign-onto each server 155-175 separately.

For example, a user may wish to access resources on various entities105-115 during the course of their work, such as using the internet tomake travel arrangements. The user first logs-on to the company'snetwork server 155 utilizing a client device 125. The user may manuallyor via a script, enter their user name and password in order to logon tothe network server 155. The network server 155 provides an internetportal.

The user may then navigate using a browser to the website of an airline115. The user will likely be required to enter a user name, password andthe like to book a flight using a corporate account. Similarly, the usermay then navigate to a car rental agency to reserve a rental car. Onceagain, the user may be requested to enter a name, password and the liketo reserve the car. Similarly, the user may also navigate to a websiteof a hotel chain to reserve a room. Once again, the user may berequested to enter a name, password and the like to reserve the room.The need to logon to each entity's server 155 reduces the user'ssatisfaction and productivity.

The need to logon multiple times is not limited to multiple entities'servers 170, 175. For example, the user may login to their employer'snetwork server 155 to access the finance server 160. The user may againbe required to enter a username, password and the like in order to enterexpenses, such as meals, entertainment and gas, incurred during theirbusiness travel. The user may then wish to check their retirementaccount. Once again the user may be required to provide a username,password and the like to access the payroll server 165 in order to checktheir retirement account. In addition to reducing the user'ssatisfaction and productivity, the implementation of multiple logonscripts increases the cost of doing business.

Versions of single sign-on services have existed for several years.However, the conventional art single sign-on services are closedsolutions that do not offer broad interoperability. Accordingly, theSecurity Assertion Markup Language (SAML) specification is intended toprovide a solution allowing single sign-on for secure authentication andauthorization.

SAML is an extensible Markup Language (XML) standard designed forbusiness-to-business (B2B) and business-to-consumer (B2C) transactions.The SAML standard is designed for the exchange of secure sign-oninformation between a user, a relying party, and/or an issuing party.Furthermore, SAML allows issuing parties to use their own chosen methodsof authentication (e.g., personal key identifier (PKI), hash, password,or the like).

In one implementation, a SAML-compliant service, called a relying party,sends a SAML request to an issuing party, which returns a SAMLassertion. Assertions do not create a secure authentication. Thesecurity service is responsible for providing a secure authentication.Assertions are coded statements generated about events, such asauthentication, that have already occurred, as when the user providedthe correct user name and password, or the security mechanism grantedspecific permissions.

Referring now to FIG. 2A, an exemplary SAML request/assertion accordingto the conventional art is shown. As depicted in FIG. 2A, SAML requestsand assertions 210 are transmitted within a SOAP envelope 215 via HTTP220.

Referring now to FIG. 2B, an exemplary SAML data packet according to theconventional art is shown. As depicted in FIG. 2B, the data packetcomprises an HTTP header 250, a SOAP header 255 and a SAML payload 260.An assertion or response is encoded into the SAML payload 260. A SOAPheader 255 is then generated and attached to the SAML payload 260. AnHTTP header 250 is then generated and attached to the SOAP header 255and SAML payload 260. The SAML payload containing an assertion orrequest may comprise an issuer identifier, an assertion identifier, anoptional subject, an optional advice, a condition, an audiencerestriction, a target restriction, and an application specificcondition.

Upon receipt, the HTTP header 250 is processed to provide routing andflow control. The SOAP header 255 is then processed to provideinformation concerning the content of the payload and how to process it.The SAML payload 260 may then be processed to provide securityinformation.

SUMMARY OF THE INVENTION

Embodiments of the present invention provide a circle of trust on anetwork. The circle of trust provides affiliated entities a means fordetermining that a user has been authenticated. The circle of trust alsoprovides the affiliated entities a means for determining whether theycan trust the authentication provided by another entity. Embodiments ofthe present invention provide for configuring a plurality of affiliatedentities to establish a circle of trust. Embodiments of the presentinvention also provide for a circle of trust session.

In one embodiment of the present invention, the method of providing acircle of trust comprises exchanging a first certificate of a firstaffiliated and a second affiliated entity. The credential of the firstaffiliated entity is stored in a trusted partner list of the secondaffiliated entity. The credential of the second affiliated entity isstored in a trusted partner list of the first affiliated entity.Thereafter, a circle of trust session may be provided when a clientdevice initiates use of a resource on a relying party device byproviding an authentication assertion reference. The identity of theissuing party of the authentication is determined as a function of theauthentication assertion reference. The relying party sends anauthentication request containing its credential to the issuing partyThe issuing party determines if the relying party is a trusted entitybased upon whether the relying party's credential is contained in thetrusted partner list of the issuing party.

In another embodiment of the present invention, the circle of trustcomprises a plurality of affiliated entities. Each affiliated entity ina circle of trust comprises an administration module, a trusted partnerlist, a session module and/or an authentication module. Theadministration modules provide for the exchange of credentials betweeneach affiliated entity. The administration modules also cause thecredentials to be saved on each of the corresponding trusted partnerlists. The session modules provide for generating and processingauthentication requests and assertions. The session modules also providefor determining the identity of an issuing party as a function of anauthentication assertion reference. The session modules also provide fordetermining a trusted status of a particular affiliated entity as afunction of a certificate received from a relying party.

Accordingly, embodiments of the present invention provide single sign-onfor secure authentication and authorization. Embodiments of the presentinvention enable open and interoperable designs for web-based singlesign-on service functionality. Furthermore, embodiments of the presentinvention allow each affiliated entity to use their own chosen methodsof authentication (e.g., personal key identifier (PKI), hash, password,or the like). Hence, the above-described advantageous provided byembodiments of the present invention increase user satisfaction andproductivity.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not by way oflimitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 shows a block diagram of a network according to the conventionalart.

FIG. 2A shows an exemplary SAML request/assertion according to theconventional art.

FIG. 2B shows an exemplary SAML data packet according to theconventional art.

FIG. 3 shows a flow diagram of a computer implemented method ofconfiguring a circle of trust between a first and second affiliatedentity, in accordance with one embodiment of the present invention.

FIG. 4 shows an exemplary trusted partner list, in accordance with oneembodiment of the present invention.

FIG. 5 shows a block diagram of a system providing for configuring acircle of trust, in accordance with one embodiment of the presentinvention.

FIG. 6 shows a flow diagram of a computer implemented method ofproviding a circle of trust session between a first and secondaffiliated entity, in accordance with one embodiment of the presentinvention.

FIG. 7 shows a block diagram of a system providing for a circle of trustsession, in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the embodiments of theinvention, examples of which are illustrated in the accompanyingdrawings. While the invention will be described in conjunction withthese embodiments, it will be understood that they are not intended tolimit the invention to these embodiments. On the contrary, the inventionis intended to cover alternatives, modifications and equivalents, whichmay be included within the spirit and scope of the invention as definedby the appended claims. Furthermore, in the following detaileddescription of the present invention, numerous specific details are setforth in order to provide a thorough understanding of the presentinvention. However, it is understood that the present invention may bepracticed without these specific details. In other instances, well-knownmethods, procedures, components, and circuits have not been described indetail as not to unnecessarily obscure aspects of the present invention.

Referring now to FIG. 3, a flow diagram of a computer-implemented methodof configuring a circle of trust between a first and second affiliatedentity, in accordance with one embodiment of the present invention, isshown. The method of the present embodiment may be realized as a seriesof instructions (e.g., code) and information (e.g., data) that reside ona computer-readable medium, such as computer memory, and are executedand manipulated by a processor. When executed, the instructions causethe processor to implement the process of configuring a circle of trust.As depicted in FIG. 3, the method comprises receiving a certificate ofthe first affiliated entity by a second affiliated entity, at step 310.The certificate of the first affiliated entity is stored in a trustedpartner list accessable to the second affiliated entity, at step 330.The method further comprises receiving a certificate of the secondaffiliated entity by the first affiliated entity, at step 340. Thecertificate of the second affiliated entity is stored in a trustedpartner list accessable to the first affiliated entity, at step 360.

The method may be repeated for each pair of affiliated entities in thenetwork. Thus, the trusted partner list for each entity will contain arecord, comprising the certificate, for each entity on the network thatis affiliated with the particular entity.

In another embodiment of the present invention, the method comprises thesteps 310, 330, 340 and 360 of the above-described embodiment. Themethod further comprises receiving a network address of the firstaffiliated entity by the second affiliated entity, at step 320. Thenetwork address of the first affiliated entity is stored in the trustedpartner list accessable to the second affiliated entity, at step 330.The method further comprises receiving a network address of the secondaffiliated entity by the first affiliated entity, at step 350. Thenetwork address of the second affiliated entity is stored in the trustedpartner list accessable to the first affiliated entity, at step 360.

The method may be repeated for each pair of affiliated entities in thenetwork. Thus, the trusted partner list for each entity will contain arecord, comprising the certificate and a network address, for eachentity on the network that is affiliated with the particular entity.

In yet another embodiment of the present invention, the method comprisesreceiving a network address of the first affiliated entity by a thirdaffiliated entity. The network address of the first affiliated entity isstored in a trusted partner list accessable to the third affiliatedentity. The method further comprises receiving a network address of thethird affiliated entity by the first affiliated entity. The networkaddress of the third affiliated entity is stored in a trusted partnerlist accessable to the first affiliated entity.

The method may be repeated for each pair of affiliated entities in thenetwork. Thus, the trusted partner list for each entity will contain arecord, comprising the network address, for each entity on the networkthat is affiliated with the particular entity. Furthermore, anycombination of the above-described three embodiments may be utilized.Thus, the trusted partner list of a given entity may contain a recordfor each entity on the network that is affiliated with the particularentity. The record of each of the trusted partners may comprise thecorresponding certificate, network address, and/or the like,

Referring now to FIG. 4, an exemplary trusted partner list, inaccordance with one embodiment of the present invention, is shown. Thetrusted partner list comprises a plurality of records 410. In oneimplementation, each record 410 comprises an identifier of theparticular trusted entity 420 and a certificate corresponding to theparticular trusted entity 430. In another implementation, each record410 comprises an identifier of the particular trusted entity 420 and anetwork address (e.g., an internet protocol (IP) address) 440. In yetanother implementation, each record 410 comprises an identifier of theparticular trusted entity 420, a certificate corresponding to theparticular trusted entity 430, and a network address 440 correspondingto the particular trusted entity. For example, the trusted partner listfor Serve A may comprise identifiers for servers B and C, certificatesof B and C, and network address of B and C, respectively.

Referring now to FIG. 5, a block diagram of a system providing forconfiguring a circle of trust, in accordance with one embodiment of thepresent invention, is shown. As depicted in FIG. 5, each affiliatedentity (e.g., server A and B) 510, 520 provides for configuring thecircle of trust utilizing an administration module 530, 540 and atrusted partner list 550, 560. The administration modules 530, 540 ofeach affiliated entity 510, 520 provide for the exchange of credentialsand storage thereof in a corresponding trusted partner list 550, 560.The credential may comprise one or more certificates (e.g., cert1,cert2, cert3), one or more network addresses (e.g., ip1, ip2, ip3)and/or the like. Accordingly, a request sent from any of the networkaddresses and/or a request containing any one of the certificatesindicated in the credential will be acceptable.

In one implementation, the administration module 530, 540 of the firstaffiliated entity 510 (e.g., server A) transmits a certificate of thefirst affiliated entity 510 to the second affiliated entity 520 (e.g.,server B). The administration module 540 of the second affiliated entity520 receives the certificate of first affiliated entity 510 and storesit as a record in the trusted partner list 560 of the second affiliatedentity 520. The administration module 540 of the second affiliatedentity 520 transmits the certificate of the second affiliated entity 520to the first affiliated entity 510. The administration module 530 of thefirst affiliated entity 510 receives the credential of the secondaffiliated entity 520 and stores it as a record in the trusted partnerlist 550 of the first affiliate entity 510.

Alternatively, the exchange of certificates may be performed out-of-band(e.g., manually) and then loaded into the respective trusted partnerlist as per individual design. For example, one entity may user somekind of certification utility to import and store the receivedcertificate.

In another embodiment, the administration module 530 of the firstaffiliated entity 510 transmits a network address, such as an internetprotocol (IP) address, of the first affiliated entity 510 to the secondaffiliated entity 520. The administration module 540 of the secondaffiliated entity 520 receives the network address of the firstaffiliated entity 510 and stores it as a record in the trusted partnerlist 560 of the second affiliated entity 520. The administration module540 of the second affiliated entity 520 transmits the network address ofthe second affiliated entity 520 to the first affiliated entity 510. Theadministration module 530 of the first affiliated entity 510 receivesthe network address of the second affiliated entity 520 and stores it asa record in the trusted partner list 550 of the first affiliated entity510.

Referring now to FIG. 6, a flow diagram of a computer implemented methodof providing a circle of trust session between a first and secondaffiliated entity, in accordance with one embodiment of the presentinvention, is shown. The method of the present embodiment may berealized as a series of instructions (e.g., code) and information (e.g.,data) that reside on a computer-readable medium, such as computermemory, and are executed and manipulated by a processor. When executed,the instructions cause the processor to implement the process ofproviding a circle of trust session. As depicted in FIG. 6, the methodbegins with a user on a client device logging onto an issuing party(e.g., first affiliated entity), at step 605. The user provides a username, password and/or the like when logging in. The issuing partyauthenticates the client device, at step 610. The authentication processmay comprise a simple password, a personal key identifier (PKI), ahashing function or the like.

Upon authentication of the user, the issuing party returns anauthentication assertion reference to the client device, at step 615.When initiating use of a resource on another device, referred to as arelying party (e.g., second affiliated entity), the client device passesthe authentication assertion reference to the particular relying party,at step 620. The relying party determines the identity of the issuingparty as a function of the authentication assertion reference, at step625.

If communication is being provided over a single socket layer (SSL) HTTPprotocol or the like, the relying party sends an authentication requestcontaining the certificate of the relying party to the issuing party,630. The issuing party looks up the certificate in a trusted partnerlist, at 635. If the issuing party finds a match for the certificate inthe issuing party's trusted partner list, the issuing party therebyknows the identity of the relying party and that the relying party is atrusted partner.

The issuing party thereafter returns an authentication assertion to therelying party, at 655. The authentication assertion states that theclient device was, in fact, authenticated by a particular method at aspecific time and the like information. The relying party then providesthe client device with the requested resource without requiring the userto separately logon to the relying party, at 660.

If communication is being provided over a non-single socket layer (SSL)HTTP protocol or the like, the relying party sends an authenticationrequest to the issuing party, at step 640. The issuing party parses theheader of the communication packet to determine a network address of therelying party, at step 645. The issuing party looks up the networkaddress in a trusted partner list, at step 650. If the issuing partyfinds a match for the network address in the issuing party's trustedpartner list, the issuing party thereby knows the identity of therelying party and that the relying party is a trusted partner.

Again, the issuing party returns an authentication assertion to therelying party, at step 655. The authentication assertion states that theclient device was, in fact, authenticated by a particular method at aspecific time and the like information. The relying party then providesthe client device with the requested resource without requiring the userto separately logon to the relying party, at step 660.

Referring now to FIG. 7, a block diagram of a system providing for acircle of trust session, in accordance with one embodiment of thepresent invention, is shown. As depicted in FIG. 7, the circle of trustsession comprises a client device 710, an issuing party (e.g., firstaffiliated entity) 715 and a relying party (e.g., second affiliatedentity) 740. During the circle of trust session, a user login request ispassed by the client device 710 to the issuing party 715 by a SAMLauthentication request. The authentication request is transmitted fromthe client device 710 to the authentication module 725 of the issuingparty 715. The authentication request, containing the user name,password and the like, is passed within a SOAP envelope via HTTP. Theauthentication module 725 processes the packet to retrieve the username, password and the like.

The user name, password and the like is passed to an authenticationmodule 725 of the issuing party 715. The authentication process providedby the authentication module 725 may comprises a simple password, apersonal key identifier (PKI), a hashing function or the like. Theauthentication module 725 returns a SAML authentication assertion to theclient device 710, if the authentication process is successful. Theauthentication assertion comprises an authentication assertionreference.

The client device 710 passes the authentication assertion reference toeach relying party (e.g., server B) 740 when initiating use of resourcesthereon. The relying party 720 can determine the particular issuingparty 715, which authenticated the client 710, from the authenticationassertion reference. Therefore, the relying party 740 sends a SAMLauthentication query to the issuing party 715.

In one implementation, if the communication is provided over a singlesocket layer (SSL) HTTP protocol, the SAML authentication query,transmitted by the session module 745 of the rely party 740 to thesession module 720 of the issuing party 715, contains the relyingparty's 720 certificate. Upon receipt of the authentication query, thesession module 720 of the issuing party 715 looks up the certificate inits trusted partner list 730. If a match is found in the issuing party's715 trusted partner list 730, the trusted party 715 knows that therelying party 740 is the requesting entity and that the relying party740 can be trusted. Therefore, the session module 720 of the issuingparty 715 returns a SAML authentication assertion to the session module745 of the relying party 740. The SAML authentication assertion statesthat the client device 710 was, in fact, authenticated by a particularmethod at a specific time and the like information.

In another implementation, if the communication is provided over anon-single socket layer (SSL) protocol, the relying party's 740 networkaddress, such as its internet protocol (IP) address, is determined fromthe transmission layer protocol header, such as the HTTP header. Thesession module 720 of the issuing party 715 looks up the network addressin its trusted partner list 730. If a match is found in the issuingparty's 715 trusted partner list 730, the trusted party 715 knows thatthe relying party 740 is the requesting entity and that the relyingparty 740 can be trusted. Therefore, the session module 720 of theissuing party 715 returns a SAML authentication assertion to the sessionmodule 745 of the relying party 740. The SAML authentication assertionstates that the client device 710 was, in fact, authenticated by aparticular method at a specific time and the like information.

Accordingly, embodiments of the present invention provide an open andinteroperable single sign-on for secure authentication andauthorization. Embodiments of the present invention also provideaffiliated entities a means for determining that a user has beenauthenticated. Embodiments of the present invention also provide theaffiliated entities a means for determining whether they can trust theauthentication provided by another entity. Furthermore, embodiments ofthe present invention allow each affiliated entity to use their ownchosen methods of authentication (e.g., personal key identifier (PKI),hash, password, or the like). Hence, the above-described systems andmethods, provided by embodiments of the present invention,advantageously increase user satisfaction and productivity.

The foregoing descriptions of specific embodiments of the presentinvention have been presented for purposes of illustration anddescription. They are not intended to be exhaustive or to limit theinvention to the precise forms disclosed, and obviously manymodifications and variations are possible in light of the aboveteaching. The embodiments were chosen and described in order to bestexplain the principles of the invention and its practical application,to thereby enable others skilled in the art to best utilize theinvention and various embodiments with various modifications as aresuited to the particular use contemplated. It is intended that the scopeof the invention be defined by the Claims appended hereto and theirequivalents.

1. A method of providing a circle of trust comprising: receiving a firstcertificate of a first affiliated entity by a second affiliated entity;storing said first certificate of said first affiliated entity in afirst trusted partner list accessible by said second affiliated entity;receiving a second certificate of said second affiliated entity by saidfirst affiliated entity; and storing said second certificate of saidsecond affiliated entity in a second trusted partner list accessible bysaid second affiliated entity; wherein access to a resource iscontrolled as a function of said first trusted partner list or saidsecond trusted partner list.
 2. The method according to claim 1 furthercomprising: initiating use of a resource on a relying party device by aclient device, wherein an authentication assertion reference is providedby a client device; determining an identity of an issuing party as afunction of said authentication assertion reference; sending anauthentication request containing a certificate of said relying party tosaid issuing party; determining if said certificate is contained in atrusted partner list of said issuing party; sending an authenticationassertion, indicating that said client has been authenticated, from saidissuing party to said relying party when said certificate is containedin a trusted partner list of said issuing party; sending anauthentication assertion, indicating that said client has not beenauthenticated, from said issuing party to said relying party when saidcertificate is not contained in said trusted partner list of saidissuing party; and providing said requested resource to said clientdevice by said relying party when said authentication assertionindicates that said client has been authenticated.
 3. The methodaccording to claim 2, further comprising: logging-on to said issuingparty utilizing said client device; and authenticating said clientdevice by said issuing party.
 4. The method according to claim 1,further comprising: receiving a first network address of said firstaffiliated entity by said second affiliated entity; storing said firstnetwork address of said first affiliated entity in said first trustedpartner list accessible by said second affiliated entity; receiving asecond network address of said second affiliated entity by said firstaffiliated entity; and storing said second network address of saidsecond affiliated entity in said second trusted partner list accessibleby said second affiliated entity.
 5. The method according to claim 4,further comprising: initiating user of a resource on a relying partydevice by a client device, wherein an authentication assertion referenceis provided by a client device; determining an identity of an issuingparty as a function of said authentication assertion reference; sendingan authentication request from a relying party to an issuing party;determining a network address of said relying party from saidauthentication request; determining if said network address is containedin a trusted partner list of said issuing party; sending anauthentication assertion, indicating that said client has beenauthenticated, from said issuing party to said relying party when saidnetwork address is contained in a trusted partner list of said issuingparty; sending an authentication assertion, indicating that said clienthas not been authenticated, from said issuing party to said relyingparty when said network address is not contained in said trusted partnerlist of said issuing party; and providing said requested resource tosaid client device by said relying party when said authenticationassertion indicates that said client has been authenticated.
 6. Themethod according to claim 4, wherein said first network address and saidsecond network address comprises a first and second internet protocol(IP) address respectively.
 7. The method according to claim 1, furthercomprising: receiving a first network address of a third affiliatedentity by said first affiliated entity; storing said first networkaddress of said third affiliate entity in said second trusted partnerlist accessable by said first affiliated entity; receiving a secondnetwork address of said first affiliated entity by said third affiliatedentity; and storing said second network address of said first affiliatedentity in a third trusted partner list accessable by said thirdaffiliated entity.
 8. A method of providing a circle of trustcomprising: initiating user of a resource on a relying party device by aclient device, wherein an authentication assertion reference is providedby a client device; determining an identity of an issuing party as afunction of said authentication assertion reference; sending anauthentication request containing a certificate of said relying party tosaid issuing party; determining if said certificate is contained in atrusted partner list of said issuing party; sending an authenticationassertion, indicating that said client has been authenticated, from saidissuing party to said relying party when said certificate is containedin a trusted partner list of said issuing party; sending anauthentication assertion, indicating that said client has not beenauthenticated, from said issuing party to said relying party when saidcertificate is not contained in said trusted partner list of saidissuing party; and providing said requested resource to said clientdevice by said relying party when said authentication assertionindicates that said client has been authenticated.
 9. The methodaccording to claim 8, further comprising: sending an authenticationrequest from said relying party to said issuing party; determining anetwork address of said relying party from said authentication request;determining if said network address is contained in a trusted partnerlist of said issuing party; sending an authentication assertion,indicating that said client has been authenticated, from said issuingparty to said relying party when said network address is contained in atrusted partner list of said issuing party; sending an authenticationassertion, indicating that said client has not been authenticated, fromsaid issuing party to said relying party when said network address isnot contained in said trusted partner list of said issuing party; andproviding said requested resource to said client device by said relyingparty when said authentication assertion indicates that said client hasbeen authenticated.
 10. The method according to claim 9, wherein saidfirst network address and said second network address comprise a firstand second internet protocol (IP) address respectively.
 11. The methodaccording to claim 8, further comprising: logging-on to an issuing partyutilizing said client device; and authenticating said client device bysaid issuing party.
 12. A system for providing a circle of trustcomprising: a first affiliated entity comprising; a first administrationmodule; and a first trusted partner list communicatively coupled to saidfirst administration module; and said second affiliated entitycomprising; a second administration module; and a second trusted partnerlist communicatively coupled to said second administration module. 13.The system for providing a circle of trust according to claim 12,wherein said first administration module receives said credential ofsaid second affiliated entity.
 14. The system for providing a circle oftrust according to claim 13, wherein said first administration modulestores said credential of said second affiliated entity in a trustedpartner list.
 15. The system for providing a circle of trust accordingto claim 14, wherein said credential comprises a certificate.
 16. Thesystem for providing a circle of trust according to claim 14, whereinsaid credential comprises a network address.
 17. The system forproviding a circle of trust according to claim 13, further comprising: aclient device; a first affiliated entity communicatively coupled to saidclient device and a second affiliated entity, comprising; a firstsession module; and a first authentication module; and said secondaffiliated entity communicatively coupled to said client device and saidfirst affiliated entity, comprising; a second session module; and asecond trusted partner list.
 18. The system for providing a circle oftrust according to claim 17, wherein said second session moduledetermines the identity of an issuing party as a function of anauthentication assertion reference received from said client device. 19.The system for providing a circle of trust according to claim 17,wherein said first session module determines a trusted status of saidsecond affiliated entity as a function of a certificate received fromsaid second session module.
 20. The system for providing a circle oftrust according to claim 17, wherein said first session moduledetermines a trusted status of said second affiliated entity as afunction of a network address of said second session module.
 21. Asystem for providing a circle of trust comprising: a client device; afirst affiliated entity communicatively coupled to said client deviceand a second affiliated entity, comprising; a first session module; anda first authentication module; and said second affiliated entitycommunicatively coupled to said client device and said first affiliatedentity, comprising; a second session module; and a second trustedpartner list.
 22. The system for providing a circle of trust accordingto claim 21, wherein said first session module provides for securetransfer of information for authenticating a user on said client device.23. The system for providing a circle of trust according to claim 22,wherein said first session module generates and processes SAML requestsand assertions contained in SOAP envelopes.
 24. The system for providinga circle of trust according to claim 21, wherein said second sessionmodule determines the identity of an issuing party as a function of anauthentication assertion reference received from said client device. 25.The system for providing a circle of trust according to claim 21,wherein said first session module determines a trusted status of saidsecond affiliated entity as a function of a certificate received fromsaid second session module.
 26. The system for providing a circle oftrust according to claim 21, wherein said first session moduledetermines a trusted status of said second affiliated entity as afunction of a network address of said second session module.
 27. Thesystem for providing a circle of trust according to claim 21, whereinsaid first session module determines said network address of saidsession module from an HTTP header.
 28. A computer readable-mediumcontaining a plurality of instructions which when executed cause anetwork device to implement a method of providing a circle of trustcomprising: receiving a first network address of a first affiliatedentity by a second affiliated entity; storing said first network addressof said first affiliated entity in a first trusted partner listaccessable by said second affiliated entity; receiving a second networkaddress of said second affiliated entity by said first affiliatedentity; and storing said second network address of said secondaffiliated entity in a second trusted partner list accessable by saidsecond affiliated entity.
 29. The computer readable-medium according toclaim 28, further comprising initiating use of a resource on a relyingparty device by a client device, wherein an authentication assertionreference is provided by a client device; determining an identity of anissuing party as a function of said authentication assertion reference;sending an authentication request from a relying party to an issuingparty; determining a network address of said relying party from saidauthentication request; determining if said network address is containedin a trusted partner list of said issuing party; sending anauthentication assertion, indicating that said client has beenauthenticated, from said issuing party to said relying party when saidnetwork address is contained in a trusted partner list of said issuingparty; sending an authentication assertion, indicating that said clienthas not been authenticated, from said issuing party to said relyingparty when said network address is not contained in said trusted partnerlist of said issuing party; and providing said requested resource tosaid client device by said relying party when said authenticationassertion indicates that said client has been authenticated.
 30. Thecomputer readable-medium according to claim 28, further comprising:receiving a first certificate of a first affiliated entity by a secondaffiliated entity; storing said first certificate of said firstaffiliated entity in said first trusted partner list accessable by saidsecond affiliated entity; receiving a second certificate of said secondaffiliated entity by said first affiliated entity; and storing saidsecond certificate of said second affiliated entity in said secondtrusted partner list accessable by said second affiliated entity. 31.The computer readable-medium according to claim 30, further comprising:sending an authentication request containing a certificate of saidrelying party to said issuing party; determining if said certificate iscontained in a trusted partner list of said issuing party; sending anauthentication assertion, indicating that said client has beenauthenticated, from said issuing party to said relying party when saidcertificate is contained in said trusted partner list of said issuingparty; sending an authentication assertion, indicating that said clienthas not been authenticated, from said issuing party to said relyingparty when said certificate is not contained in said trusted partnerlist of said issuing party; and providing said requested resource tosaid client device by said relying party when said authenticationassertion indicates that said client has been authenticated.
 32. Thecomputer readable-medium according to claim 31, further comprising:logging-on to said issuing party utilizing said client device; andauthenticating said client device by said issuing party.